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DETAILED ACTION 

Response to Amendments/Remarks 

1 . Applicant's arguments filed on 3/1 6/2009 with respect the rejection(s) of claim(s) 1 - 
25 under 35 U.S.C. 103(a) are fully considered. The argument regarding the delay 74 
(page 2, 3 rd full paragraph) is persuasive. Therefore, the finality of the rejection has been 
withdrawn. However, upon further consideration, new rejections are made as described in 
the following. 

2. Applicant's argument that "RFC 2676 has no description of selecting a shortest path 
based on delay" (page 2, 1 st full paragraph) is not persuasive. RFC 2676 clearly discloses 
using QoS parameters that indues delay ("minimize delay", 2 nd paragraph of Section 3.2, 
page 18) as a criterion in finding the shortest path. 

3. regarding to the rejection of claim 1 based on Caro and RFC 2676, applicant argues 

a) "RFC 2676 does not select a path based on the actual time traveled by a data 
packet" (3 rd paragraph of page 3); 

b) "There is no disclosure in RFC 2676 for selecting, from a set of routers, a 
particular router that is associated with a first actual time that is a shortest time among all 
times associated with router in the set of routers, wherein the first actual time has been 
updated with a previous actual time taken fro a previous data packet for a previous data 
packet to travel to a previous destination indicated by the previous data packet, as 
featured in Claim 1"; 

c) "Further, the Office Action cannot point to any place therein ... disclosing 
selecting a router based on a first actual time"; 
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d) "... the probabilistic route selection in Caro is replaced with selecting a neighbor 
router that has a lowest amount of delay time from source node to the destination node in 
searching the best routing. As a result, Caro's critical probabilistic model including 
selecting routers based on probabilistic values must be replaced in this proposed 
combination and its operating principal violated" (page 16-17). 

In response, Examiner respectfully disagrees: 

a) RFC 2676 clearly discloses using QoS parameters including delay ("minimize 
delay", 2 nd paragraph of Section 3.2, page 18) as criterion in finding the shortest path; 

b) RFC 2676 disclose OSPF routing path finding using QoS parameters including 
delay ("minimize delay", 2 nd paragraph of Section 3.2, page 18) as the criterion for the 
shortest path. OSPF protocol maintains a routing table from which the shortest path is 
found based on delay, which is interpreted as the shortest path. 

c) the shortest delay is used to measure the shortest path as specified in RFC 2676. 
At a given time, the routing table provides a shortest path from a set of routers to a specific 
destination, which is interpreted as the first actual time. Notice that the shortest time is 
never defined or mentioned in Specification, Examiner interpret it as best understood. 

d) Caro teaches building and updating a routing table based on a probabilistic 
model. After the routing table is built or updated, a shortest path can be found between any 
two nodes, which does not violate Caro's critical probabilistic model in any way because 
Caro's model is used in building or updating the routing table, not in finding the shortest 
path. 

Claim Rejections - 35 USC § 101 

4. 35 U.S.C. 101 reads as follows: 
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Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions 
and requirements of this title. 

5. Claim 18 is rejected under 35 U.S.C. 101 because the claimed invention is directed 
to non-statutory subject matter. 

claim 18 recites "A computer-readable medium which is defined in 
Specification as "any medium that participates in providing instructions to processor 1004 for execution. 
Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and 
transmission media . . . Transmission media can also take the form of acoustic or light waves, such as those 
generated during radio wave and infrared data communications", [0149]. "light waves, SUCh as those 
generated during radio wave" are non-statutory subject matter. 

Specification 
Claim Rejections - 35 USC §112 

6. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming 
the subject matter which the applicant regards as his invention. 

7. Claim 9 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. 

Claim 9 recites the limitation "receiving a backward ant data packet that indicates a second 
amount of time taken for the forward ant data packet to travel to the specified destination". This limitation 

needs clarity. It is unclear how the travel time of a backward ant data packet could indicate 
the travel time of forward ant data packet. 

For examination on the merits, the claims will be interpreted as the best understood. 
Claim Rejections - 35 USC § 103 
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8. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth 
in section 102 of this title, if the differences between the subject matter sought to be patented and the prior 
art are such that the subject matter as a whole would have been obvious at the time the invention was 
made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall 
not be negatived by the manner in which the invention was made. 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 
459 (1966), that are applied for establishing a background for determining obviousness 
under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 

9. Claims 1-7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Teruhi 
et al (US 20030072269, hereinafter Teruhi, which includes IETF standard for RTP, RFC 
1889, as cited by Teruhi in [0045]) in view of Apostolopoulos, et al., INTF RFC 2676 "QoS 
Routing Mechanisms and OSPF Extensions", August 1999 (hereinafter RFC 2676) 

For claim 1, Teruhi discloses a method of updating a routing table ("routing table", 
[0053]; or suggested by OSPF, [0003], which updates a routing table), comprising the 
computer-implemented steps of: 

selecting, from a set of routers, a particular router that is associated with a first 
actual path is a shortest path among all paths associated with routers in the set of routers 
(selecting a router from a set of routers associated with link 31-33 which has a shortest 
path to a destination, as shown in FIG. 18, that has the shortest path from the source node 
1 1 to the destination node 12); 
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wherein the first actual path has been updated with a previous actual path taken for 
a previous data packet to travel to a previous destination indicated by the previous data 
packet (routing table is updated based on previous traffic, [0007]); 

sending a first data packet (first RTCP-SR sent from node 1 1 to node 12 in FIG. 9) 
to the particular router; 

receiving a second data packet (first RTCP-RR sent from node 12 to node 1 1 in 
FIG. 9) that indicates an second amount of time taken for a destination back to the sending 
router (the time between the first RTCP-RR packet is sent from Node 12 and the time it 
arrives at Node 1 1 , FIG. 9, as disclosed by Section 6.3.2 in page 28 of RFC 1 889); 

wherein the destination indicated by the first data packet is the same as the 
previous destination indicated by the previous data packet (FIG. 10, RTCP-RR packet is 
sent to the destination following a path in the routing table built based on the previous data 
packet); 

wherein the second data packet is sent from the destination indicated by the first 
data packet (FIG. 9, where RTCP-RR is sent from the destination of RTCP-SR). 
Teruhi is silent on the following: 

the shortest path is measured in terms of a shortest time (a first actual time); 

updating the shortest time based on the second time (the trip time of the second 
packet from the destination to the sending router); and 

updating the routing table based on information contained in the second data 
packet. 

In the same field of endeavor (routing), RFC2676 teaches finding the shortest path 
(OSPF, page 1) in terms of traveling time (delay, line 8 of first paragraph in Section 1 .2, 
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Page 5, which is the time difference between the time that a RTCP packet leaving a node 
A and the time the packet arrives a node B, and is equivalent to the actual traveling time 
from the node A to the node B) from the routing table that are updated based on the 
received packets ("the QoS routing table that gets built as the algorithm progresses ... at 
each (hop count) iteration, intermediate results are recorded in a QoS routing table", 2 nd 
paragraph, page 12), which is the shortest time of the all the previous packets traveled 
from the set of nodes to the destination node. 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to combine Teruhi with RFC2676 to choose the shortest path (in 
term of traveling time) and update the first (shortest) time and the routing table based on 
the information from the second packet for the benefit of efficiency of network because 
they are analogous. 

As to claim 2, Teruhi in view of RFC 2676 discloses the method of Claim 1 , further 
comprising: updating a path associated with both the destination and the particular router 
(by considering the particular router as the sending router in claim 1). 

As to claims 3 and 6, Teruhi in view of RFC 2676 discloses the method of Claim 1 ; 
Teruhi is silent on the second data packet information including the bandwidth available 
on a path taken by the second data packet. 

RFC 2676 teaches the routing packet containing QoS information ("QoS routing", 1 s 
paragraph of Page 5), including bandwidth information ("available bandwidth", Line 7 of 
Section 1 .2, Page 5). 



Application/Control Number: 10/645,255 Page 8 

Art Unit: 2416 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to include bandwidth information in the second packet for the benefit 
of efficiency of providing better routing options. 

As to claims 4 and 7, Teruhi in view of RFC 2676 discloses the method of Claim 1 , 
whether a path taken by the first data packet is feasible (a path found based on updated 
routing table is feasible). 

As to claim 5, Teruhi in view of RFC 2676 discloses the method of Claim 1 , further 
comprising: updating, based on information contained in the second data packet, a list of 
routers that indicates all routers in a path taken by the first data packet to a router that sent 
the first data packet to a present router (This is equivalent to finding the shortest path 
based on the updated routing table with the information of the second data packet). 
10. Claims 8 and 18-20 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over RFC 1247 "OSPF Version 2", July 1991 (hereinafter RFC 1247) in view of RFC 2676. 

For claims 8 and 18-20, RFC 1247 discloses a method, a computer storage 
medium, an apparatus for updating a routing table ("a routing table", page 1, 2 nd 
paragraph), comprising: 

A network interface (the network interface of the router OSPF router, page 1 , 2 nd 
paragraph) that is coupled to a data network for receiving one or more packet flows 
therefrom; a processor (CPU of "OSPF router", page 1, 2 nd paragraph) executing 
instructions 

for each neighbor router in a set of neighbor routers (neighboring routers, page 4), 
selecting a shortest path to a specified destination via a set of neighbor routers (shortest 
paths, 3rd paragraph of 1 .1 , page 2); 
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wherein the shortest path has been updated with a previous data packet to travel to 
the specified destination (Link State Update, table 8, page 26, where the routing is updated 
based previous routing data packets) ; 

send a first data packet to the specified destination (sending Link State Request 
packet to the destination, 3rd paragraph of page 74); 

receiving a second data packet from the specified destination (receiving sending 
Link State Request packet from the destination, 3rd paragraph of page 74); 

wherein the second data packet is sent from the destination (FIG. 10, where RTCP- 
RR is sent from the destination of RTCP-SR); 

updating the routing table based on information contained in the second data packet 
("updating the necessary part of its database", 3rd paragraph of page 74). 

RFC 1247 is silent on the measurement parameter for the shortest path in routing 
table is the time (or delay) for a packet to travel from a source router to a destination 
router. 

RFC 2676 discloses using delay (line 8 of Section 1 .2, Page 5) as one of QoS 
parameters for routing measurement (the shortest delay includes the information of delay 
times of all the previous packets to the destination), which are used to the updating routing 
table. RFC 2676 teaches enhancement of OSPFv2 by RFC 1247. It would be obvious for 
one skilled in the art to combine RFC 1247 with RFC 2676 to use time delay in the routing 
table, and update the routing table for the shortest path in term of delay time between two 
routers. 
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Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to using delay time as routing measurement parameters to update 
routing table. 

1 1 . Claim 1-25 are rejected under 35 U.S.C. 103(a) as being 103(a) as being 
unpatentable over Gianni Di Caro et al., "AntNet: Distributed Stigmergetic Control for 
Communications Networks", Journal of Artificial Intelligence Research, 12/98 (hereinafter 
Caro) in view of RFC 2676 (which includes the recited RFC 1247). 

For claim 1, Caro discloses a method of updating a routing table ("the routing 
table", page 327, step 3), comprising the computer-implemented steps of: 

sending a first data packet from a sending router to a given destination via a 
particular router so that the packet arrives at the destination (sending forward ant, step 1 of 
page 326, line 1-3); wherein the first time has been updated with a previous time taken for 
a previous data packets (the routing table is built based on previous routing data packets); 

receiving a second data packet that indicates an second amount of time from taken 
for the destination back to the sending router (receiving backward ant, step 5 of page 327); 

selecting the path according to a criterion that the first packet is predicted to reach 
the destination, wherein the second data packet is sent from the destination indicated by 
the first data packet ("The backward ant takes the same path as that of its corresponding 
forward ant, but in the opposite direction", step 6, page 328); 

updating the shortest time based on the second time ("updates .. the traffic M_k", 
step 7, page 328 in view of "The model M maintains absolute distance/time estimates", 3 rd 
paragraph, page 326); and 
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updating the routing table based on information contained in the second data packet 
("updates ... the routing table", step 7, page 328-329). 

Caro is silent on the criterion for the shortest path is based on the shortest time 
(the first time, which is a shortest time that the first packet is predicted to reach the 
destination); 

In the same field of endeavor (routing), RFC2676 teaches routing the shortest path 
in term of traveling time (delay, line 8 of first paragraph in Section 1 .2, Page 5). 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to combine Caro with RFC 2676 to choose the shortest path (in term 
of traveling time) and update the first (shortest) time and the routing table based on the 
information from the second packet for the benefit of efficiency of network because they 
are analogous. 

As to claim 2, Caro in view of RFC 2676 discloses the method of Claim 1 , Caro 
further discloses the method comprising: updating a path associated with both the 
destination and the particular router ("updates ... the routing table", step 7, page 328). 

As to claims 3 and 6, Caro in view of RFC 2676 discloses the method of Claim 1 , 
but are silent on the second data packet information including the bandwidth available on a 
path taken by the second data packet. 

RFC 2676 teaches the routing packet containing QoS information ("to support 
QoS", Line 3 of Section 1.2, Page 5), particularly bandwidth information ("available 
bandwidth", Line 7 of Section 1 .2, Page 5). 
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One skilled in the art would have been motivated to apply the teaching by RFC 
2676 to the second packet to provide additional information for better routing options. 
Furthermore, OSPF technology taught by 2676 is cited by the applicant in the disclosure. 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to include bandwidth information in the second packet for the benefit 
of efficiency of providing better routing options. 

As to claims 4 and 7, Caro and RFC 2676 disclose the method of Claim 1 , whether 
a path taken by the first data packet is feasible (a path predicted to take a shortest time 
from the source node to the destination node is always feasible). 

As to claim 5, Caro and RFC 2676 disclose the method of Claim 1 , Caro further 
discloses the method comprising: updating, based on information contained in the second 
data packet, a list of routers that indicates all routers in a path taken by the first data 
packet to a router that sent the first data packet to a present router ("updates ... the routing 
table", step 7, page 328-329). 

For claim 8 and 18-20, Caro discloses a method, an apparatus for updating a 
routing table (steps 1-7, page 326-330), comprising: 

a network interface (the network interface of the router holding the routing table) 
that is coupled to a data network for receiving one or more packet flows therefrom; a 
processor (CPU of the router holding the routing table) executing instructions 

for each neighbor router in a set of neighbor routers (suggested by "every network 
node", line 1 of step 1 , page 326), selecting a path to a specified destination via a set of 
neighbor routers (line 1-2 of step 3 and step 5, page 327); 
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wherein the shortest path has been updated with a previous time taken for a 
previous data packet to travel to the specified destination (line 5-30 of page 331 , 
determining is based on M=Local traffic model and T=Node routing table); 

send a first data packet to the specified destination ("destination node is reached", 
step 5, page 327; or LanuchForwardAnt(destination_node, source_node), line 13 of page 
331); 

receiving a second data packet from the specified destination; wherein the second 
data packet is sent from the specified destination (suggested by "The backward ant takes 
the same path as that of its corresponding forward ant, but in the opposite direction", step 
6, page 328) 

updating the routing table based on information contained in the second data packet 
(step 7, page 328; or UpdateLocalRoutingTable, line 26 of Page 331). 

Caro discloses using trip time as parameter in routing table ("How to Score the 
Goodness of the ant's Trip Time", Section 4.2, title and 1 st paragraph, page 330), but does 
not explicitly disclose that the path is the shortest in terms of delay time from a source 
router to a destination router and the shortest amount of time is updated with data packet 
travel to the specified destination. 

In the same field of endeavor, RFC 2676 discloses OSPF extensions on routing 
based on path QoS parameters (lines 1-5 of page 3). Since time delay (trip time) is one of 
QoS parameters, it would have been obvious to one skilled in the art to use the shortest 
time (delay time) as the criteria for the shortest path. 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to combine Caro with RFC 2676 to selecting a particular neighbor 
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router that has a lowest amount of delay time from source node to the destination node in 
searching the best routing. 

For claim 9, Caro discloses a method of updating a routing table (Node routing 
table, page 331, line 6), the method comprising the computer-implemented steps of: 

for each neighbor router in a set of neighbor routers predicted to be required for a 
data packet to travel to a specified destination ("every network node", line 1 of step 1 , page 
326), associating the neighbor router with an amount of time ("elapsed_time", page 331 , 
line 1 9; or step 2 of page 326); 

receiving a forward ant data that indicates the specified destination (suggested by 
"The backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328; or algorithm shown in page 331); 

selecting, based on one or more first specified criteria (goodness of ant's travel 
time, title and first paragraph of Section 4.2, page 330; or step 3 of page 327), a subset of 
the set of neighbor routers (from page 331 , line 14-20 where forward ant can only be 
passed to neighboring routers one at a time; selecting from the routing table a subset of 
neighbor routers through which paths to the destination go); 

in response to receiving the forward ant data packet, selecting, from the subset of 
neighbor routers, to the specified destination, among amounts of time associated with 
neighbor routers in the subset of neighbor routers (the paths from the routing table are 
updated based on received forward ant data packet, first paragraph of Section 4.2, page 
330; or "updates the corresponding statistics and the routing table", step 7); 

wherein the amount of time has been updated with a previous amount of actual time 
taken for a previous data packet to travel to the specified destination ("step 7 i) of page 
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328, where Mk that includes travel time information is updated based on previous travel 
time of ants; or algorithm shown in page 331); 

sending the forward ant data packet to the particular neighbor router ("destination 
node is reached", step 5, page 327; or LaunchForwardAnt (destination_node, 
source_node), lines 10-12, page 331); 

receiving a backward ant data packet that indicates a second amount of time taken 
for the forward ant data packet to travel to the specified destination ("The backward ant 
takes the same path as that of its corresponding forward ant, but in the opposite direction", 
step 6, page 328; the travel time is the second amount of time); 

wherein the backward ant data packet is sent from the specified destination ("The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328); 

determining, based on information indicated in the backward ant data packet, 
whether one or more second specified criteria are satisfied (line 5-30 of page 331 , 
determining a path based on criteria specified in M=Local traffic model and T=Node routing 
table); and 

if the one or more second specified criteria are satisfied (a second time criteria used 
to find proper path based on M and T; notice that criteria used for selecting paths depend 
on user requirements and may have multiple values), then performing steps comprising: 

updating the first amount of time based on the second amount of time 
(suggested by UpdateLocalTrafficModel, line 24 of Page 331 ; where traffic model is 
updated); and 



Application/Control Number: 10/645,255 Page 16 

Art Unit: 2416 

if one or more third specified criteria are satisfied (suggested by "The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328, which indicates the backward ant knows whether the 
path taken by the forward ant is followed, which is equivalent to the path feasibility flag), 
then updating, based on information indicated in the backward ant data packet, the routing 
table (suggested by UpdateLocalRoutingTable, line 26 of Page 331). 

Caro does not explicitly disclose selecting a particular neighbor router that is 
associated with a first amount of time that is a lowest amount of time, but defines a 
goodness in terms of trip time ("as estimated using the associated trip time", line 27-34 of 
page 329) that is used as a measure for determining routing between nodes. 

In the same field of endeavor, RFC 2676 discloses OSPF extensions on routing 
based on path QoS parameters (lines 1-5 of page 3). Since time delay is one of most 
important QoS parameters, it would have been obvious to one skilled in the art to use the 
shortest trip time (delay time) as the criteria for the shortest path. 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to combine Caro with RFC 2676 to selecting a particular neighbor 
router that has a lowest amount of delay time from source node to the destination node in 
searching the best routing. 

As to claim 10, Caro in view of RFC 2676 discloses the method of Claim 9, wherein 
the one or more first specified criteria comprise a criterion that no neighbor router in the 
subset of neighbor routers is contained in a list of routers that have already been visited by 
the forward ant data packet ("choosing among the neighbors it did not already visit", line 1- 
2 of page 327). 
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As to claim 11, Caro in view of RFC 2676 discloses the method of Claim 9, Caro 
further discloses the method comprising: 

determining whether any neighbor router in the set of neighbor routers is associated 
with an amount of time that is lower than the first amount of time ("as estimated using the 
associated trip time", line 27-34 of page 329); and 

if any neighbor router in the set of neighbor routers is associated with an amount of 
time that is lower than the first amount of time, then updating the forward ant data packet 
to indicate a present router in a loop-avoidance router field of the forward ant data packet 
(cycle avoidance, step 4 of page 327, line 1-3). 

As to claim 12, Caro in view of RFC 2676 discloses the method of Claim 1 1 , Caro 
further discloses wherein a loop-avoidance router field ("memory of their paths and of the 
traffic conditions found", lines 1-2 of step 2 in page 326) of the backward ant data packet 
indicates a router indicated by the loop-avoidance router field of the forward ant data 
packet (notice that a backward ant packet has the same structure as forward ant packet). 

As to claim 13, Caro in view of RFC 2676 discloses the method of Claim 12, Caro 
further discloses wherein the one or more second specified criteria comprise a criterion 
("trip time", line 10 of page 329) that the router indicated by the loop-avoidance router field 
of the backward ant data packet is not contained in a list of routers that the forward ant 
visited after visiting a present router (step 3 of page 327, line 1-2; notice that a backward 
ant packet has the same structure as forward ant packet). 

As to claim 14, Caro in view of RFC 2676 discloses the method of Claim 9, but is 
silent on wherein the one or more specified criteria comprise a criterion that the second 
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amount of time is lower than any other amount of time, relative to the specified destination, 
among amounts of time associated with neighbor routers in the set of neighbor routers. 

However, the criterion that the second amount of time is lower than any other 
amount of time is used in OSPF (disclosed by RFC 2676) in determining the shortest path 
in term of time. 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to specify criterion that the second amount of time is lower than any 
other amount of time in order to find the shortest path. 

As to claim 15, Caro in view of RFC 2676 discloses the method of Claim 9, but are 
silent on the method comprising: determining whether a router from which the backward 
ant data packet was received matches a router associated with the destination in the 
routing table; and if the router from which the backward ant data packet was received does 
not match the router associated with the destination in the routing table, then updating a 
path feasibility flag of the backward ant to indicate that a path taken by the forward ant is 
not feasible. 

However, the method requires the forward ant packet and the backward ant packet 
go through the same route (in opposite direction). If the backward ant packet cannot 
following the same route as the forward ant packet, the ant packet will be destroyed 
according to Caro ("if an ant is forced to return to an already visited node, the cycle's 
nodes are popped from the ant's stack and all the memory about them is destroyed", step 
4 of page 327). It is a common practice in the art that one way of destroying/delete a 
packet is to set a flag of the packet so that it can be destroyed at proper time or location 
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(such as taught by Tarin, US 2001/0000536 A1, "deleted cells are marked by a flag", 
[247]). 

Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to set a flag of the received backward ant packet if routing information 
of the packet does not match the routing table of the router in order to comply with the 
protocol. 

As to claim 16, Caro in view of RFC 2676 discloses the method of Claim 15, Caro 
further discloses the one or more third specified criteria comprise a criterion that the path 
feasibility flag of the backward ant indicates that the path taken by the forward ant is 
feasible (suggested by "The backward ant takes the same path as that of its corresponding 
forward ant, but in the opposite direction", step 6, page 328, which indicates the backward 
ant knows whether the path taken by the forward ant is followed, which is equivalent to the 
path feasibility flag). 

As to claim 17, Caro in view of RFC 2676 discloses the method of Claim 9, Caro 
further discloses the one or more third specified criteria comprise a criterion that a path 
taken by the forward ant data packet from a present router to the specified destination 
does not include any routers that are identified in a potential upstream node list (suggested 
by "The backward ant takes the same path as that of its corresponding forward ant, but in 
the opposite direction", step 6, page 328, which indicates the backward ant knows whether 
the path taken by the forward ant is followed, which is equivalent to the path feasibility 
flag). 

As to claim 21, Caro in view of RFC 2676 discloses the method of Claim 20, Caro 
further discloses the stored sequences of instructions include instructions which, when 
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executed by the processor, cause the processor to further carry out: updating, based on 
information contained in the second data packet, a path associated with both the 
destination and the particular router ("updates ... the routing table", step 7, page 328-329 
or UpdateLocalRoutingTable, line 26 of Page 331; the routing table includes all the paths, 
including a path associated with both the destination and the particular router). 

As to claim 22, Caro in view of RFC 2676 discloses the method of Claim 20, Caro 
further discloses wherein the stored sequences of instructions include instructions which, 
when executed by the processor, cause the processor to further carry out: updating, based 
on information contained in the second data packet ("updates ... the routing table", step 7, 
page 328-329 or UpdateLocalRoutingTable, line 26 of Page 331), an indication of an 
amount of bandwidth available ("characterized by a bandwidth", lines 10-1 1 of page 322) 
on the path taken by the second data packet (the path is disclosed by "The backward ant 
takes the same path as that of its corresponding forward ant, but in the opposite direction", 
step 6, page 328). 

As to claim 23, Caro in view of RFC 2676 discloses the method of Claim 20, Caro 
further discloses wherein the stored sequences of instructions include instructions which, 
when executed by the processor, cause the processor to further carry out: updating, based 
on information contained in the second data packet ("updates ... the routing table", step 7, 
page 328-329 or UpdateLocalRoutingTable, line 26 of Page 331), whether a path taken by 
the first data packet is feasible (suggested by "The backward ant takes the same path as 
that of its corresponding forward ant, but in the opposite direction", step 6, page 328; a 
mechanism that ensures the path is feasible based on the updated routing table). 
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As to claim 24, Caro in view of RFC 2676 discloses the method of Claim 20, Caro 
further discloses wherein the stored sequences of instructions include instructions which, 
when executed by the processor, cause the processor to further carry out: updating, based 
on information contained in the second data packet, a list of routers that indicates every 
router in a path taken by the first data packet from a router that sent the first data packet to 
a present router (suggested by "The backward ant takes the same path as that of its 
corresponding forward ant, but in the opposite direction", step 6, page 328). 

As to claim 25, Caro in view of RFC 2676 discloses the method of Claim 20, Caro 
further discloses wherein the stored sequences of instructions include instructions which, 
when executed by the processor, cause the processor to further carry out: updating, based 
on information contained in the second data packet to indicate an amount of bandwidth 
available (routing table is "characterized by a bandwidth", lines 10-11 of page 322) on the 
path taken by the second data packet (bandwidth available is considered as a criterion of 
feasible path in algorithm specified in steps 1-7 of pages 326-330, which includes routing 
based on bandwidth). 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jianye Wu whose telephone number is (571)270-1665. 
The examiner can normally be reached on Monday to Thursday, 8am to 7pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Seema Rao can be reached on (571)272-3174. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status information 
for unpublished applications is available through Private PAIR only. For more information 
about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on 
access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866- 
217-9197 (toll-free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786-9199 (IN 
USA OR CANADA) or 571-272-1000. 

/Jianye Wu/ 
Examiner, Art Unit 2416 
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